SRC Technical Note 
1997 - 009 

June 30, 1997 



Juno-2 Language Definition 



Greg Nelson and Allan Heydon 



3030030 

Systems Research Center 

130 Lytton Avenue 
Palo Alto, California 94301 



http://www.research.digital.com/SRC/ 



Copyright ©Digital Equipment Corporation 1997. All rights reserved 



Contents 



1 Preface 

2 Values 

3 Terms 

4 Variables 



5 Literals 1 

5.1 Real Literals 1 

5.2 Text Literals 2 

5.3 NIL 2 

6 Functions 2 

6.1 Standard Syntax 2 

6.2 Built-in Functions 2 

6.3 User-Defined Functions 3 

7 Formulas 3 

7.1 Standard Syntax 3 

7.2 Formulas Are Always Defined 3 

7.3 Atomic Formulas 4 

7.4 Compound Formulas 4 

7.5 Constraints 4 

7.6 User-Defined Predicate Symbols 5 

8 Commands 5 

8.1 Abort, Skip 5 

8.2 Assignment 5 

8.3 Guard 5 

8.4 Sequential Composition 6 

8.5 Else Command 6 

8.6 Command Grouping 6 

8.7 Iteration 6 

8.8 Alternative Construct 6 

8.9 Projection 6 

8.10 Save Command 7 

8.11 Procedure Call 7 

9 Definitions 7 

9.1 Constants 7 

9.2 Global Variables 8 

9.3 Predicates 8 

9.4 Pure Functions 8 

9.5 Procedures 8 

fO Closures 9 

10.1 Closure Introduction 9 

10.2 Closure Application 9 

11 Modules 10 

11.1 Import 10 

11.2 Modules 10 

11.3 Comments 10 



A Constraint Solving 10 

B Syntax 12 

B.l Operators and Keywords 12 

B.2 EBNF Grammar 12 

B.2.1 Compilation Unit Productions . . 12 

B.2. 2 Declaration Productions 12 

B.2. 3 Command Productions 13 

B.2.4 Formula Productions 13 

B.2.5 Expression Productions 13 

B.2. 6 Miscellaneous Productions .... 14 

B.3 EBNF Syntax For Tokens 14 



i 



1 Preface 



2 Values 



Juno-2 is a constraint-based language intended for graph- 
ics applications. A Juno-2 program describes a picture; 
a Juno-2 implementation renders the picture. This paper 
describes the language only; for a description of the Juno- 
2 system as a whole, see "The Juno-2 Constraint-Based 
Drawing Editor" [HN94]. 

The Juno-2 language is useful for drawing pictures, and 
also interesting for its simplicity, uniformity, and its pro- 
visions for solving constraints. We hope this paper will be 
useful as a reference to Juno-2 users, and also of interest 
to programming language users and designers. 

The theoretical basis for Juno-2 constraints rests on 
the following two observations: (1) as an imperative lan- 
guage, Juno-2's semantics are defined in terms of predi- 
cate transformers, and (2) a constraint is just another name 
for a predicate. For afficionados of Dijkstra's calculus of 
guarded commands [Dij76, Nel87], Juno-2 can be defined 
in one sentence: it consists of Dijkstra's predicate trans- 
formers acting on the predicates of the theory of the real 
numbers together with a pairing function. 

For the rest of us, Juno-2 is an imperative, block- 
structured, untyped language with a syntax and control 
structure not too distant from Algol. But its data struc- 
tures are more like Lisp's than Algol's: instead of arrays, 
records, and pointers, Juno-2 provides only scalars and or- 
dered pairs, since this is the simplest set of data structures 
sufficient to represent the points and lists of points needed 
for the graphics primitives. The primitive graphics opera- 
tions provided by Juno-2 are similar to those of PostScript 
[Ado90]. 

Any constraint expressible in Euclidean geometry (or, 
equivalently, in the multiplicative theory of the real num- 
bers) can be included in a Juno-2 program. The imple- 
mentation solves the constraints using numerical methods. 

The provisions for constraints make the Juno-2 lan- 
guage novel. For example, the command 

VAR rINr*r = 2->x := r END 

sets x to one of the square roots of two. The user can 
supply hints for unknowns to control the non-determinism 
inherent in underconstrained systems. 

To support libraries of reusable graphics programs, 
Juno-2 also includes modules. The module system bor- 
rows the notion of a public view from Oberon [Wir89]. 

Juno-2 is an extension of Juno-1 [Nel85]. Juno-2 bor- 
rows its overall semantic framework from Juno- 1 , includ- 
ing hints. Going beyond Juno-1, Juno-2 provides a richer 
value space and more powerful extensibility, including 
user-defined constraints and constraints containing exis- 
tential quantifiers. 



The universe of values of a Juno-2 program is the small- 
est set that includes the real numbers, the text strings, the 
special value nil, and is closed under the formation of 
ordered pairs. 

The language also supports closures (procedures paired 
with environments). Closures are represented as ordinary 
Juno-2 pairs according to a convention that is private to 
the implementation. 

3 Terms 

A term is an expression denoting a partial function from 
the state of the computation to the universe of values. Syn- 
tactically, a term is either a variable, a literal, or a function 
applied to arguments that are themselves terms. 

4 Variables 

Syntactically, a variable is an identifier, possibly qualified 
by a module name. Global variables are defined in mod- 
ules (described below), and local variables are defined in 
blocks (also described below). 

Juno-2 is untyped: every variable ranges over the entire 
universe of values. 

5 Literals 

Juno-2 has three kinds of literal constants: real (numeric) 
literals, text literals, and the special literal nil. 

5.1 Real Literals 

A real literal has the form decimal [ E exponent ], 
where decimal is a non-empty sequence of decimal dig- 
its, optionally containing a decimal point, and exponent 
is a non-empty sequence of decimal digits, optionally pre- 
ceded by a "+" or The literal denotes decimal 
times ten raised to the given exponent. If "E expo- 
nent" is omitted, exponent defaults to zero. Case is not 
significant: "e" is as good as "e". Embedded spaces are 
not allowed. 
For example, 

1 1. .5 3.1415 5E1 5.0e-l 
are legal, but 

2.0e+a 5.0Ex 
are not. 
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5.2 Text Literals 



6.2 Built-in Functions 



A text literal is a sequence of zero or more printing char- 
acters or escape sequences enclosed in double quotes. 
Printing characters are all printing ISO-Latin- 1 characters 
except double-quote and backslash. 

The only way to include a double-quote, backslash, or 
non-printing character such as newline in a text literal is 
with an escape sequence. Here are the legal escape se- 



quences: 




\n 


newline 


\f 


formfeed 


\t 


tab 


\r 


carriage return 


w 


backslash 


\" 


double quote 


\nnn 


character with octal code nnn 



A backslash that is not a part of one of these escape se- 
quences is a static error. 

5.3 NIL 

nil is a distinguished value used to terminate lists. See ls shorthand for 
Section 6.2 below. ( t ( t (_ 



Pair introduction. Within parentheses, the comma is a 
function that forms ordered pairs. That is, the term ( x , y ) 
is the ordered pair of x and y; it is defined for any values 
x and y. For example, 

(0, (1, NIL)) 
("Alan", "Turing") 

are valid terms. The inner parentheses in the first example 
are required. The expression (x, y , z ) is syntactically in- 
valid; you must instead specify either the pair ( x , ( y , z ) ) 
or the pair ( ( x , y ) , z ) . 

Pair elimination. The functions car and cdr are defined 
on pairs: 

CAR(p)=x if and only if p=(x,y) for some y 
CDR(p)=y if and only if p=(x,y) for some x 

List introduction. Within square brackets, the comma is 

a function that forms lists. More precisely, the term 

[ti, t2, t„] 



(t„, NIL) ...))) 



6 Functions 

A pure function is a rule that defines a result value in terms 
of given argument values; at most one result can be asso- 
ciated with any tuple of arguments. Functions may be 
partial; that is, it may be that for some argument values no 
result is defined. Pure functions never have side effects on 
the machine state; they are not to be confused with func- 
tional procedures (defined in Section 9.5). 

What happens when you try to compute an undefined 
function? This is a question about commands and their 
computations, which we will get to later (see Sections 7.2, 
8.2, and 9.5). For now, it is best to remember that a pure 
function is not a rule for computing a result value, but only 
a rule for defining it. 

6.1 Standard Syntax 

The standard syntax for a function application is 

f(ti, t2, t„) 

where f names a function and ti, t2, ■ ■ -, t„ are terms. 
Several of the built-in functions have non-standard syn- 
tax; for example, the infix arithmetic operators. The next 
section describes Juno-2's built-in functions. 



that is, for the list of t, represented by a nest of ordered 
pairs as in Lisp. The list can have length one; that is, [ t ] 
is shorthand for (t, nil) . But the list can't have length 
zero; that is, [ ] is not a legal shorthand for nil. 



Arithmetic functions. 

arithmetic functions: 



Juno-2 provides the following 



x + y x plus y 

x - y x minus y 

x * y x times y 

x / y x divided by y 

x DIV y FLOOR (x/y) 

x MOD y x - (y * (x DIV y) ) 

- x minus x 

FLOOR ( x ) the greatest integer not exceeding x 

ceiling (x) the smallest integer not less than x 

round ( x ) the nearest integer to x 

MAX(x,y) the larger of x and y 

MiN(x,y) the smaller of x and y 

abs (x) the absolute value of x 

The infix and prefix operators are listed in groups with 
equal binding power, and the groups are listed in order 
of increasing binding power. Parentheses can be used to 
override the binding powers. For example, 
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a + - c * d means a + ( (- c) * d). 

Infix arithmetic operators with the same binding power 
are left associative. For example, 



b + c means (a 



b) + c. 



The arithmetic functions are defined only on numbers; for 
example nil+0 is undefined. Also, x/y, x mod y, and x 
div y are undefined if y is zero. 

In addition, the following trigonometric and exponen- 
tial functions are defined: 

SiN(x) the sine of x 

COS(x) the cosine of x 

atan ( y , x ) the angle whose tangent is y / x 

ln ( x ) the natural logarithm of x 

exp(x) the exponential of x 

All angles are in radians. The range of the atan function 
is the half-open interval [— it, it). The sign of the result 
agrees with the sign of y. LN (x) is undefined if x is not 
positive. 

Coordinate translation. A point is an ordered pair of real 
numbers. Since Juno-2 is intended for graphics, points 
and lists of points occur quite frequently. Juno-2 has a 
built-in infix operator for coordinate transformations on 
points: p rel c. Here p must be a point, say (x,y), 
and c must be an ordered pair of points, say (a, b) . Its 
definition is: 

(x,y) REL (a,b) means 

the point with coordinates (x, y) in the 
coordinate system whose origin is at a and 
whose unit x vector ends at b. 

Here is a figure that illustrates rel: 



(0,1) REL (a,b) 




(1,1) REL (a,b) 



(1,0) REL (a,b) 



Text concatenation. The infix operator & denotes text 
concatenation: 

t & u t concatenated with u 

The function is undefined if either argument is not a text. 

6.3 User-Defined Functions 

So much for the built-in functions. You can also define 
new functions, as explained in Section 9.4. Defined func- 
tions can be used in terms exactly like built-in functions; 
they always have the standard syntax described in Sec- 
tion 6.1. 



7 Formulas 

A formula is a condition that is either true or false in any 
state of a computation. Syntactically, a formula is either a 
predicate symbol applied to one or more terms (an atomic 
formula), or a logical combination of other formulas (a 
compound formula). Like terms, formulas never have side 
effects. 

7.1 Standard Syntax 

The standard syntax for an atomic formula is 

p(ti, t2, t„) 

where p names a predicate and ti, t2, ■ ■ -, t„ are terms. 
The only atomic formulas with non-standard syntax are 
true, false, and applications of the built-in infix rela- 
tions. 

7.2 Formulas Are Always Defined 

A pure function can be undefined, but a formula is always 
true or false, never undefined. This may require some get- 
ting used to. Here are four corollaries of this rule: 

1 . A boolean operator applied to arguments of the wrong 
type is false. For example, 

NIL < 3 



If Juno-2 had complex arithmetic, we could equiva- i s false, rather than undefined 
lently write the definition as follows: 



a + p 



(b 



p REL (a, b) 
As a final example, 

(0.5, 0) REL (a, b) 
is the midpoint of the segment between a and b. 



2. An atomic formula is false if any of the terms that it 
contains is undefined. For example, 



1/0 = 
is false. 



1/0 



3. Compound formulas are defined in terms of their con- 
The function p rel c is undefined if p is not a point stituent formulas. For example, not p is the logical com- 



or if c is not a pair of points. 



plement of p, so 
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NOT (1/0 = 1/0) 

is true. 

4. Formulas are not themselves terms. You cannot use a 
formula in place of a term; for example 

(x = y) = (y = x) 

is syntactically invalid. 

7.3 Atomic Formulas 

Constant Formulas. 

true the predicate symbol that is always true 
false the predicate symbol that is always false 

Type Formulas. If x is any value, then 

real (x) means x is a real number; 

int (x) means x is an integer; 

text (x) means x is a text; 

pair (x) means x is an ordered pair. 

In FORTRAN and Algol, integers and reals are disjoint 
types. But in Juno-2, as in numerical mathematics, the in- 
tegers are contained within the reals. Therefore, int (x) 
implies real (x) . 

Equality. If s and t are any values, then 

s = t means s and t are identical; 
s # t means s and t are not identical. 

Order. If x and y are real numbers, then 

x < y means x precedes y; 

x > y means x exceeds y; 

x <= y means x is at most y; 

x >= y means x is at least y. 

These atomic formulas are false if either x or y are not 
numbers. 

Near. The infix predicate symbol ~, read "near", is con- 
sidered to be satisfied by any pair of values, but is use- 
ful for giving hints to the Juno-2 constraint solver, as de- 
scribed in Section 8.9 and Appendix A. 

Geometric Formulas. A point is a pair of real numbers. 
A segment is a pair of points, called the endpoints of the 
segment. If p and q are points and s and t are segments, 
then 

p HOR q means CDR(p) = CDR(q); 

p ver q means car (p) = car ( q ) ; 

s CONG t means s and t have the same length; 

s para t means s is parallel to t. 

The atomic formulas p HOR q and p ver q are true if 
p=q. The formula s para t is true if either sort has 
length zero. These formulas are false if their arguments 
do not have the correct type. 



7.4 Compound Formulas 

Propositional Connectives. If p and q are formulas, then 

p OR q means either p or q is true; 
p and q means both p and q are true; 
not p means p is false. 

These are listed in order of increasing binding power. 
Parentheses can be used to override the binding power; 
for example, the parentheses are necessary in 

(x < y OR x < z) AND u < x 

Existential Quantification. If v is a variable and p is a 
formula, then 

(E v : : P) 

is a formula. (Not any formula p is allowed, as we will see 
in Section 7.5.) In theory, this existential quantification is 
true if there exists some value for v that satisfies p. In 
practice, it is true only if Juno-2's constraint solver can 
find such a value. To help the solver determine a satisfying 
assignment for v, you may need to supply it with a hint for 
v's initial value; see Appendix A. 

Juno-2 provides a shorthand for introducing variables 
in existential quantifications with hinted or fixed values. 
If t is a term, then 

(E x = t : : P) means (Ex : : x = t AND P) 
(E x ~ t : : P) means (Ex : : x ~ t AND P) 

The variable x is said to be frozen in the first case and 
hinted in the second case. 

Furthermore, the construction 

(E vi , v 2 , . . ., v„ : : P) 

is shorthand for 

(E vi : : (E v 2 : : ... (E v„ : : P) ... ) ). 

Any of the v's may be frozen or hinted. However, it is a 
static error for the same variable to occur more than once 
in the list vi, . . ., v„. 
For example, 

(Ex:: x*x=z) is equivalent to z >= 0; 

(E x,y :: z=(x,y)) is equivalent to PAIR ( z ) . 

7.5 Constraints 

The notation (E v : : P) is allowed only if the for- 
mula p is a constraint. A constraint is a formula, syn- 
tactically restricted in order to make it easy to solve for its 
unknowns. The following functions, predicate symbols, 
and connectives can be used in constraints: 

literals, 
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pair introduction: ( x , y ) , 

list introduction: [x, y, z], 

CAR, CDR, 
+, -, *, /, 

SIN, COS, ATAN, LN, EXP, 
REL, 

TRUE, FALSE, 
REAL, TEXT, PAIR, 

HOR, VER, CONG, PARA, 
AND, 

existential quantification, 
user-defined pure functions, 
user-defined predicates. 

The following are forbidden in constraints: 

DIV, MOD, 

FLOOR, CEILING, ROUND, 

MAX, MIN, ABS, 

INT, 

#, <, <=, >, >=, &, 
OR, NOT, 

functional procedures. 

Functional procedures, defined in Section 9.5 below, are 
not to be confused with pure functions. 
For example, 

(E z : : z * z = 2) 

is a legal formula, since * and = are allowed in constraints. 
But the formulas 

(E z : : INT (z) AND z + z = 4) 

(E z : : (z & "be" & z) = "abebcabe") 

are illegal, since neither INT nor & is allowed in a con- 
straint. 

There is one exceptional case: OR is allowed in a con- 
straint if one of its arguments is the predicate symbol 
true and its other argument is a constraint. This is a de- 
generate case, since true OR P is equivalent to true. 

7.6 User-Defined Predicate Symbols 

So much for the built-in formulas. You can also define 
new predicate symbols, as explained in Section 9.3. De- 
fined predicate symbols can be used in atomic formulas 
exactly like built-in predicate symbols. They always have 
the standard formula syntax described in Section 7.1. 



8 Commands 

Executing a command produces a sequence of state tran- 
sitions, the eventual outcome of which is to loop forever, 
cause a checked runtime error, or halt in some state. Since 
Juno-2's constraint solver is non-deterministic, a Juno-2 
command may be non-deterministic as well. That is, the 
outcome of a command need not be functionally deter- 
mined by the initial state. 

Associated with each command is a predicate on the 
initial state called its guard. A command can be activated 
only in a state where its guard is true. An attempt to acti- 
vate a command in a state where its guard is false is said 
to fail. 

Failure is not to be confused with abortion of the com- 
putation due to a run-time error. A computation that 
aborts may change the state before it aborts, but an attempt 
to activate a command where its guard is false fails imme- 
diately, without changing the state. To implement these 
semantics without backtracking, the Juno-2 grammar syn- 
tactically restricts the placement of commands that may 
potentially fail. 

We write "grd ( S ) " to denote the guard of the com- 
mand S. If grd (S) =true, then S can be activated in any 
state, and we say that S is total. Otherwise, S is partial. 

The remainder of this section lists the Juno-2 com- 
mands. 

8.1 Abort, Skip 

The command abort causes a checked runtime error. It 
is total. 

The command skip is a no-op. It is also total. 

8.2 Assignment 

The assignment command has the form 

vi, V2, v„ := ti, t2, t„ 

where vi, v 2 , . . ., v„ are distinct variables and ti, t2, . . ., 
t„ are terms. The effect is to evaluate all the terms and 
then set each variable to the value of the corresponding 
term. For example, 

x, y := y, x 

swaps x and y. 

The assignment command is total. If any term t,- is 
undefined, the assignment is equivalent to abort. 

8.3 Guard 

If p is a formula and S is a command, the guarded com- 
mand 
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P -> s 

fails if p is false, and otherwise is the same as s. We have 

grd(P -> S) = (P AND grd(S)). 

8.4 Sequential Composition 

If S is a command and T is a total command, then 

S ; T 

means: execute S, then execute T. The guard of "s ; t" 
is the guard of s. Notice that since T is total, there is no 
danger that T will fail after s has changed the state. 

The guard arrow has weaker binding power than the 
semicolon; thus in 

x < y -> max := y; min := x, 

the guard covers both assignments. 

8.5 Else Command 

If S and S ' are commands, the command 
S I S' 

(read "s else s ' ") executes s if its guard is true, otherwise 
it executes s ' . It fails only if both s and s ' fail: 

grd(S | S' ) = grd(S) OR grd(S')- 

The else operator has weaker binding power than the 
guard arrow and semicolon. 

8.6 Command Grouping 

Curly braces can be used to override the binding power of 
the operators on commands. For example, 

P -> A ; B | C 

is equivalent to 

{ P -> { A ; B } } | C 

which is different from 

P -> A ; { B | C }. 

8.7 Iteration 

If S is a command, then the total command 

DO S OD 

repeatedly executes s until its guard becomes false. That 
is, this command is equivalent to 

{ S ; DO S OD } | SKIP. 

For example, 



DOn<m->m : = m - n 
I m<n->n := n - m 
OD 

will compute the greatest common divisor of the two non- 
negative integers n and m. 

8.8 Alternative Construct 

If S is a command, then the total command 

IF S FI 

is equivalent to 

S I ABORT. 

For example, 

IF x >= y -> m := x 
I y >= x -> m := y 
FI 

is equivalent to m := max(x, y). In particular, both 
commands abort if either x or y are not numbers: the if 
command aborts because both guards are false; the assign- 
ment aborts because max is defined only on numbers. 

8.9 Projection 

If v is a variable and S is a command such that grd ( S ) is 
a constraint, then the command 

VAR V IN S END 

introduces v as a local and executes s. The scope of v 
starts at in and ends at end. Its initial value is chosen so 
as to make the guard of s true; if the constraint solver 
cannot find such a value, the command fails. We have: 

grd (VAR v IN S END) = (E v : : grd(S)). 

For example, the command 

VAR r IN 

r*r=2->x := r 
END 

will set x to one of the square roots of two. If you care 
which square root you get, you can use the near predicate 
to give a hint to the solver: 

VAR r IN 

r ~ 1 AND r*r = 2->x:=r 
END. 

This has the same formal semantics as the previous ver- 
sion, but in practice will set r to the positive square root 
of two. 

Juno-2 solves constraints by numerical methods; the 
near predicate provides the initial value for the numerical 
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iteration. The hint you supply can be an arbitrary expres- 
sion, and you can supply a different hint for each variable. 
For more information on the near predicate and Juno-2's 
constraint solver, see Appendix A. 

Similar to the syntax for existential quantification, 
Juno-2 provides a shorthand for introducing variables in 
projections with hinted or fixed values. If t is a term, then 

var x = t in S end means 

VAR X IN X = t -> S END 

var x ~ t in S end means 

VAR X IN X ~ t -> S END 

Furthermore, the command 

VAR vi, V2, v„ IN S END 

is shorthand for 

VAR Vi IN 

VAR V„ IN 

S 

END 

END. 

As before, any of the v's may be frozen or hinted, and it 
is a static error for the same variable to occur more than 
once in the list vi , . . . , v„ . 
By definition, we have 

grd(VAR vi , v 2 , v„ IN S END) = 

(E vi , V2, . . ., v„ : : grd (S) ) . 

As another example, here is a program that reverses the 
list p, using an auxiliary variable q: 

q := NIL; 

DO 

VAR u, v IN 

p = (u, v) -> 
q := (u, q) ; 
p := v 

END 
OD; 

p := q 

As a final example, 

VAR a, b IN 

INT (a) AND INT (b ) 
AND a * b = 89801 -> 
x, y := a, b 

END 

is illegal, since INT is not allowed in constraints. 



8.10 Save Command 

If m is the name of a module and T is a total command, the 
total command 

SAVE M IN T END 

is shorthand for 

M.SaveO; T; M. Restore (). 

Notice that since T follows a semi-colon in this transla- 
tion, it must be total. 

This is useful for temporarily changing various as- 
pects of the program state, as illustrated in the built-in 
PostScript module PS. 

8.11 Procedure Call 

A procedure call is a total command. See Section 9.5 for 
the syntax and semantics of a procedure call. 

9 Definitions 

You can extend Juno-2 by defining your own constants, 
global variables, predicates, pure functions, and proce- 
dures. These definitions are grouped into modules, as de- 
scribed in Section 1 1 . 

Each definition is either public or private; private defi- 
nitions are preceeded by the optional keyword private. 
Private definitions are hidden from clients, and they are 
elided in public views of the module. 

Constants, global variables, and procedures are imper- 
ative programming constructs, so except for the initializa- 
tion order of constants and global variables, their defini- 
tion order within a module does not matter. Predicate and 
pure function definitions, on the other hand, express re- 
lations in first-order logic (where recursive definitions are 
disallowed), so there are restrictions on their definition or- 
der. 

9.1 Constants 

If idi, . . . , id„ are names and ti, . . . , t„ are terms, the 
definition 

CONST idi = ti, id„ = t„; 

defines each id, as a read-only name for the value of the 
term t,-. Here are some examples: 

CONST Pi = 3.14159, Zero = SIN(Pi); 
CONST Data = [("Jan", 2.3), ("Feb", 5)]; 
CONST Len = Text . Length (" Juno-2 ") ; 
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It is an unchecked error for any t, to depend on the initial 
value of a constant or global variable declared at or after 
id, in the same module. For example, the definition 

CONST x = 3 * x - 2; 

is an unchecked error because it is self -referential. 

9.2 Global Variables 

If vi , . . . , v„ are names and 1 1 , . . . , t„ are terms, the def- 
inition 

VAR vi [:= ti] , v„ [:= t„] ; 

introduces vi, . . ., v„ as global variables with initial val- 
ues 1 1 , . . ., t„ . If any t,- is omitted, the corresponding v ( - 's 
initial value is arbitrary. It is an unchecked error for any 
t, to depend on the initial value of a constant or global 
variable declared at or after v, in the same module. 

9.3 Predicates 

A predicate definition has the form 

PRED id(args) IS C END; 

where c is a constraint and args is a list of distinct identi- 
fiers. It defines id ( args ) to be equivalent to C. A defined 
predicate can be used in a formula just like a built-in pred- 
icate. 

Here are some example predicate definitions: 

PRED R3(p) IS 
(E x, y, z : : 

p = [x, y, z] AND REAL ( X ) AND 
REAL (y) AND REAL (z) ) 

END; 

PRED Colinear(a, b, c) IS 

(a, b) PARA (a, c) 
END; 

In a predicate definition, the constraint c may not refer 
to any procedures, nor to any constants, global variables, 
predicates, or pure functions defined at or after id in the 
same module. 

9.4 Pure Functions 

A pure function definition has the form 

FUNC res = id (args) IS C END; 

where res and id are identifiers, args is a list of identi- 
fiers, there are no duplicates among the identifiers res and 
args, and C is a constraint. The effect is to define id to 
be the function with the property that res = id ( args ) 



is logically equivalent to c. A defined pure function can 
be used in a term just like a built-in function. 

Here are some example pure function definitions: 

FUNC n = Half (m) IS m = n + n END; 

FUNC y = Cadr(l) IS 

(E x, tail :: 1 = (x, (y, tail))) 
END; 

In a pure function definition, the constraint c may not refer 
to any procedures, nor to any constants, global variables, 
predicates, or pure functions defined at or after id in the 
same module. 

If a pure function has more than one possible result for 
some input, the result computed for that function is non- 
deterministic. For example, 

FUNC y = Sqrt(x) IS y * y = x END; 

is unadvised, since y is not determined uniquely from x. 
However, such a function can be used reliably if the func- 
tional result is given a suitable hint — for example: 

a ~ 1 AND a = Sqrt (2) . 

It is perfectly all right for a pure function to be partial; 
both Half and Cadr above are partial, since Half is de- 
fined only on numerical arguments, and Cadr is defined 
only on lists with at least two elements. 

9.5 Procedures 

A procedure definition has the form 

PROC [outs :=] [(inouts):] id(ins) IS 

S 

END; 

where outs, inouts, and ins are lists of identifiers (col- 
lectively called the formal parameters of the procedure), 
id is an identifier (the name of the procedure) and s is 
a total command (the body of the procedure). The ":=" 
must be omitted if out s is empty, and the initial " ( ) " and 
":" must be omitted if inouts is empty; however, the 
second " ( ) " are required even if ins is empty. Addition- 
ally, the initial " ( ) " may be omitted if inouts contains 
exactly one identifier. 

Procedure Call. A call to the procedure has the form 

[outActs :=] [ (inoutActs) :] id(inActs) 

where outActs and inoutActs are lists of variables and 
inActs is a list of terms (collectively called the actual 
parameters of the call). The " : =" must be omitted if out- 
Act s is empty, and the initial " ( ) " and " : " must be omit- 
ted if inoutActs is empty; however, the latter "()" are 
required even if inActs is empty. Additionally, the initial 
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" () " may be omitted if inoutActs contains exactly one 
variable. 

The meaning of the call is the same as the following 
block 

VAR outs, inouts, ins IN 

inouts, ins := inoutActs, inActs; 
S; 

outActs, inoutActs := outs, inouts 
END 

Any formal variable that occurs in any actual must be re- 
named before applying this rule. (Since the formals are 
dummies, renaming them consistently does not affect the 
meaning of the procedure definition.) Note that by defini- 
tion of the assignment command (see Section 8.2), the call 
is equivalent to abort if any of the inActs is undefined. 
For example, after the definitions 

PROC st:Push(x) IS st := (x, st) END; 

PROC x := st:Pop() IS 

x, st := CAR(st), CDR(st) 
END; 

the command 

st := NIL; 

st:Push(l); st:Push(2); 
x := st:Pop() 

would leave st = [ 1 ] and x = 2. 

Functional Procedures. A procedure is functional if it 
has exactly one out parameter, like the Pop procedure 
above. Such a procedure can be used as a function, with 
the obvious meaning. For example, here is a recursive 
definition of a procedure for appending two lists: 

PROC res := Append (y, z) IS 
y = NIL -> res := z 
I res := (CAR (y ) , Append (CDR (y ) , z)) 
END; 

Juno-2's framework is geared toward pure functions, but 
we include functional procedures for their notational con- 
venience. However, they should be used with care. 
Functional procedures cannot be used within constraints. 
Functional procedures may have side-effects, but it is dan- 
gerous to use such procedures functionally, since Juno-2 
may evaluate the subexpressions of an expression in any 
order. Finally, note that a functional procedure whose 
body aborts is semantically different from an undefined 
pure function. 



10 Closures 

Flexible drawing libraries often require user-supplied pro- 
cedures as parameters. For example, a scatter-plot pack- 
age can accept a user-supplied procedure for drawing the 
points in the plot, or an animation package can accept a 
procedure for drawing each frame of an animation. For 
this reason, the Juno-2 language supports closures. 

A closure is a procedure (called the body of the closure) 
paired with a list of values (called the environment of the 
closure). 

Any built-in or user-defined procedure p is considered 
a closure with body p and an empty environment. 

10.1 Closure Introduction 

The built-in functional procedure CLOSE creates closures 
with non-empty environments. The command 

CLOSE (cl, ti, t„) 

evaluates to a closure whose body is the body of the clo- 
sure cl and whose environment is el's enviroment ex- 
tended at the right by the list of values 1 1 , . . . , t„ . 

10.2 Closure Application 

The built-in procedure apply applies a closure. The ef- 
fect of the command 

[outs] :=[ (inouts) : ] APPLY (cl, ti, t„ ) 

is to apply the body of the closure cl to the given out pa- 
rameters, the given inout parameters, and the in param- 
eters formed by concatenating the list of values in el's en- 
vironment with the values of the actual arguments 1 1 , 
t„. The out and inout arguments are optional, just as for 
an ordinary procedure call. 
For example, 

VAR 

cl := CLOSE (Text .Cat, "Hello, "); 
nm := APPLY (cl, "Juno!"); 

initializes nm to "Hello, Juno!". 

The environment of a closure provides values only for 
the in parameters of its body, not for any out or in- 
out parameters. Actual out and inout parameters can 
be supplied when the closure is applied. 

Argument counts are checked dynamically at apply 
time. For out and inout parameters, the number of ac- 
tuals must equal the number of formals of the closure's 
body. For in parameters, the number of values in the 
closure environment together with the number of actuals 
must sum to the number of the body's formal in parame- 
ters. 
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11 Modules 

Larger Juno-2 programs are organized into modules, 
which are collections of declarations. The module A must 
import the module B to refer to the names declared in B. 
The qualified identifier B . N is used within A to refer to the 
entity in B named N. 

Within a module, each name can be declared either pub- 
lic or private. Only public names are visible to importers. 

11.1 Import 

The import statement has the following form: 

IMPORT Mi, M„; 

where the M, are module names. 

import makes the names of the modules Mi, . . ., M„ 
visible. To refer to an entity named N in any M, , the im- 
porter must use the qualified identifier M, . N. Importing a 
module provides access to the names it declares, but not 
to those it imports. The import relation must be acyclic. 

11.2 Modules 

A module has the form: 

MODULE id ";" { Imports } { Defns } 

where id is an identifier that names the module, { im- 
ports } is a sequence of import statements, and {Defns } 
is a sequence of definitions (or comments). 

All defined names in the module id are visible with- 
out qualification in the module. The names defined in the 
module and the visible imported names must be distinct. 

11.3 Comments 

Comments may appear in a module wherever a module 
header, import statement, or definition is legal. Com- 
ments can appear at top-level only; this is to simplify the 
pretty-printer. Comments may be nested. Public and pri- 
vate comments have the following forms: 

(* public comment *) 
/ * private comment * / 

Private comments are elided from public module views. 



A Constraint Solving 

In principal, the semantics of Juno-2 depend only on the 
semantics constaints, and not on the implementation of 
the constraint solver. But in practice, if you are using 
Juno-2 you will sometimes need to know something about 



how the solver works. This section is intended to provide 
some helpful information. 

There are three steps in solving a system of constraints. 
The solver (1) propagates known values, (2) propagates 
hints, and (3) uses the numeric solver. 

The numeric solver uses Newton-Raphson iteration. 
This is quite reliable (even for the consistent but over- 
constrained case) provided that adequate hints are given. 
But if any variable involved in a non-linear constraint is 
unhinted, the solver is unlikely to succeed. Thus, if the 
solver isn't working properly there is probably a problem 
with the initial hints or with their propagation. 

Initial hints. You specify the initial hints with the near 
constraint. If s and t are terms, then 

s ~ t 

is semantically true, but it supplies a hint to the solverr 
for one or more unknowns. 

Propagating known values. The solver's first step uses 
equalities to eliminate unknowns by propagating known 
values. That is, if x=E or E=x is a constraint, where x 
is an unknown and E is an expression all of whose vari- 
ables have known values, then x is reclassified as known 
instead of unknown, and given the known value of E. For 
example, in 

VAR x, y, z IN 

x=5 AND x=y AND y*y=z -> ... 
END 

the known value 5 for x is propagated to y and then the 
known value 2 5 of y*y is propagated to z. In this simple 
case, propagation of known values has solved all the con- 
straints, but in general, some unknowns and constraints 
will remain. 

In propagating known values, the solver does not use 
algebraic facts about arithmetic. For example, from x=2 
and x+y=4 it is unable to propagate the known value 2 
to y. Therefore the propogation phase leaves y as an un- 
known, and the solver uses the numeric solver on the sys- 
tem 2+y=4 with unknown y. 

Propagating hints. The solver's second step uses equal- 
ities and near constraints to propagate hints to as many 
unknowns as possible. That is, if x=E or E=x or x~E 
or E~x is a constraint, where x is an unhinted unknown 
and E is an expression all of whose variables either have 
known values or hints, then x is given as a hint the value 
of E, where the unknowns in E are considered to have their 
hinted values. For example, in 

VAR x, y, z IN 

x=l AND x~y AND 

y+0.5=z AND z*z=2 -> ... 
END 
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the known value 1 for x is propagated to become the 
hinted value for y, and then this hint is used to give the 
hint 1.5 to z. Thus the numeric solver is invoked on the 
equation z*z=2 with the initial value z=l . 5. 

In propagating hints, the solver does not use algebraic 
facts about arithmetic. But hints for ordered pairs are used 
to produce hints for their components. For example, con- 
sider the command 

VAR p IN 

p ~ (0.5, 0) REL ((0, 0), (2, 2)) AND 
CAR(p) * CAR(p) = 2 -> ... 
END 

The solver will use the value of the rel expression (which 
is ( 1 , 1 ) ) as a hint for p. This will cause the solver to use 
1 as the hint for car (p) . Therefore, the Newton-Raphson 
solver will solve x*x=2 with 1 as the initial value of x, 
producing a final solution of p = (1.414, 1). 

Errors in hints. If the propagation of hints terminates 
without making use of one of the user's near constraints, 
the Juno compiler gives the error message unused near 
constraint and refuses to compile the program. The al- 
ternative would be to invoke the numeric solver from an 
initial value that ignored one or more of the user's near 
constraints, which would be likely to be fail in some con- 
fusing way. 

Two common problems lead to the unused near con- 
straint error. One of them is to accidentally produce a 
cycle of hints, as in 

VAR x,y IN 

x ~ (y,5) AND y ~ CAR(x) -> ... 
END 

The second is to write near constraints that Juno can't 
use because it doesn't use algebraic identities to propa- 
gate NEAR constraints, as for example in: 

VAR x, y IN 

x=2 AND y+x~5 AND y*y=10 -> ... 
END 

Such systems can be solved by rewriting the NEAR con- 
straints so the unknowns appear alone on one side of the 
~, like this: 

VAR x, y IN 

x=2 AND y~5-x AND y*y=10 -> ... 
END 
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B Syntax 

In this appendix, we describe the Juno-2 syntax: its operators, keywords, reserved words, grammar, and tokens. 

B.l Operators and Keywords 

Here are Juno-2's operators: 

; . ,:(){}[]:=:: I 

->~=#<> >=<=+-*/& 

Here are Juno-2's keywords: 

MODULE IMPORT PRIVATE CONST VAR PRED FUNC PROC 
IS SKIP ABORT IF FI DO OD SAVE IN END NIL TRUE 
FALSE OR AND NOT CONG PARA HOR VER E REL DIV MOD 

Here are Juno-2's reserved identifiers, which cannot be redefined: 

FLOOR CEILING ROUND MAX MIN ABS SIN COS ATAN LN 
EXP CAR CDR REAL TEXT PAIR INT CLOSE APPLY 

Identifiers beginning with the underscore character are also reserved. 



B.2 EBNF Grammar 

The following grammar uses an extended BNF notation in which { s } is a sequence of zero or more occurrences of S, 
and [S] is zero or one occurrence of s. Tokens are written as all upper-case identifiers, as double-quoted strings, or 
surrounded by angle brackets. Each production list ends with a period. 



B.2.1 Compilation Unit Productions 



Module = [ ModDecl ] { Import } { Decl } . 

ModDecl = MODULE <Id> 

Import = IMPORT IdList 

Decl = [ PRIVATE ] Declaration 

Comments may appear anywhere at the top level of a module. 



B.2.2 Declaration Productions 



Declaration = CONST ConstDecls 

| VAR VarDecls 

PRED PredDecl 

FUNC FuncDecl 

PROC ProcDecl. 
ConstDecls = ConstDecl { "," ConstDecl }. 

ConstDecl = <Id> "=" Expr . 

VarDecls = VarDecl { "," VarDecl }. 

VarDecl = <Id> [ ":=" Expr ]. 

PredDecl = <Id> "(" IdList ")" IS Constraint END. 

FuncDecl = <Id> "=" <Id> "(" IdList ")" IS Constraint END. 

ProcDecl = ProcHead IS TotalCmd END. 

ProcHead = [ IdList ":=" ] [ IdList2 ":" ] <Id> "(" [ IdList 



] ") 
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B.2.3 Command Productions 



TotalCmd = Cmd. 

Cmd = SKIP | ABORT 

| QldList ":=" ExprList 

| Cmd ";" TotalCmd 

I Formula "->" Cmd 

I Cmd " I " Cmd 

I DO Cmd OD 

! IF Cmd FI 

I VAR NearVarList IN Cmd END 
I SAVE <Id> IN TotalCmd END 
I ProcedureCall 
| " { " Cmd " } " . 

ProcedureCall = [ QldList ":=" ] [ QIdList2 ":" ] Qld "(" [ExprList] ")". 

The infix command operators (namely, ":=", "->", and " |") are listed in decreasing order of binding power. 

The grammar defines a TotalCmd simply as a Cmd, but there are syntactic restrictions on TotalCmds. The com- 
mands skip, abort, assignment, DO . . . OD, if . . . FI, save . . . in . . . end, and procedure call are always To- 
talCmds. In addition, the commands T; A, A | T, { T }, and var NearVarList in t end are each TotalCmds 
when the command T is a TotalCmd and none of the variables in NearVarList has a hint. Any other command is 
considered partial, even if its guard is semantically true. 



B.2.4 Formula Productions 



Constraint 

Formula 

AndFormula 

NotFormula 

SimpleFormula 



RelationFormula 
RelationOp 

PredicateUse 
SolveFormula 



Formula . 

AndFormula [ OR Formula ] . 

NotFormula [ AND AndFormula ] . 

SimpleFormula ] NOT NotFormula. 

TRUE | FALSE 

" (" Formula ") " 

RelationFormula 

PredicateUse 

SolveFormula . 

Expr RelationOp Expr . 

H^H | ll_ll | II ^ II | II < II j II y II | " < = 

CONG | PARA | HOR I VER. 

Qld " (" [ ExprList ] ") " ■ 

"(" E NearVarList Constraint 



The grammar defines a Constraint simply as a Formula, but Constraints must conform to the restrictions listed 
in Section 7.5. 



B.2.5 Expression Productions 



Expr = Exprl [ REL Exprl ] . 

Exprl = Expr2 [ AddOp Exprl ] 

Expr2 = Expr3 [ MultOp Expr2 

Expr3 = Expr4 | "-" Expr3 . 

Expr4 = Qld 

I NIL 

I Literal 

I " ( " Expr " ) " 

| " ( " Expr " , " Expr " ) " 
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I " [" ExprList "] " 

I FunctionCall . 
AddOp = "+" | "-" | 

MultOp = "*" I "/" I DIV | MOD. 

Literal = <Number> | <TextLiteral> . 

FunctionCall = [ QIdList2 ":" ] Qld "(" [ ExprList ] ")". 



B.2.6 Miscellaneous Productions 



IdList 


<Id> 


II 1 


<Id> } . 


IdList2 


<Id> 


" (' 


IdList ")"■ 


Qld 


<Id> 


II 1 


<Id> ] . 


QldList 


Qld 


II 1 


Qld } . 


QIdList2 


Qld 


" (' 


QldList ")"■ 


ExprList 


= Expr 


II 1 


Expr } . 


NearVarList 


= NearVar 


II 1 


NearVar } . 


NearVar 


<Id> 




| "=") Expr 



B.3 EBNF Syntax For Tokens 

To read a token, first skip all blanks, tabs, newlines, carriage returns, vertical tabs, and form feeds. Then read the 
longest sequence of characters that forms an Operator, id, Number, TextLiteral, or comment. The syntax of 
comments is described in Section 1 1.3. 

An Id is a case-significant sequence of letters, digits, and underscores that begins with a letter. An Id is a keyword 
or reserved identifier if it appears in the corresponding list above, and an ordinary identifier otherwise. 

In the following grammar, terminals are characters surrounded by double-quotes and the special terminal DQUOTE 
represents double-quote itself. 



Operator 



_ ii . ii | ii . . ii | ii ii | ii . _n | ii . H | H ^ H | ii j ii | H ^ H | H j H 
I ii | ii | ii | ii | ii | ii | | ii _ ii | ii ^. ii | ii ^ ii | ii ^ ii | " >= 

ii^—n | ii ii | ii _|_ ii | ii _ ii | ii*n | ii j ii | ii £ ii | ii M 



Id 



( Letter | "_" ) { Letter | Digit | "_" } 



Number 
FloVal 
Exponent 



FloVal [ Exponent ] 

{ Digit } ( Digit I Digit 



Digit ) { Digit } 



( 



] Digit { Digit } . 



TextLiteral 
Escape 

PrintingChar 



DQUOTE { PrintingChar | Escape } DQUOTE. 

ii \^ ii " n " | " \ " " t " | " \ " " r" " | " \ " " f " | " \ " " \ " 

"\" DQUOTE | "\" OctalDigit OctalDigit OctalDigit . 
Letter | Digit | OtherChar. 



OctalDigit 
Digit 
Letter 
OtherChar 



II Q II | II ^ II j | II y II 

OctalDigit | "8" | "9". 
"A" | "B" | ... | "Z" 

II II | II | II | M Q H | II ^ II | 



I 



II I II 



II II 



II _ II 



II II 



| " ? " | " @ " 1 " [ " | " ] " | 



I 



| ExtendedChar . 



I "a' 

II o, II I 



j „ b r 

II c II | 



II J II | II . II | II . II | 



. I " z " . 

II ^ II I " ) 



I II = II I II y II 



I " { " I " I " I " } ' 



ExtendedChar 



any char with ISO-Latin-1 code in [ 8_240 . . 8_377 ; 
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